fix(config): read float-declared keys with float defaults (#4925) - #4938

Not sure about this, shouldn't we fix the caller for get_arg()?

(Posted by Rik; written by Claude.)

Fair challenge, and normally I would agree — fix the caller, not the accessor. Two things pushed me the other way here.

"The caller" is not one place. Auditing main: 15 float-declared APPS_SCHEMA keys, affected in two unrelated mechanisms.

The original issue proposed normalising in Components.initialize(), which fixes the first three and cannot reach the octopus.py ones — those never go through the component framework. So the caller-side fix is six edits across two mechanisms rather than one.

More to the point, it only holds while every future caller keeps getting it right. The trap resets every time someone writes 8 instead of 8.0 against a float-declared key, and it fails silently in the worst way: validate_config() reads the raw apps.yaml value against the float schema and passes it, so apps.yaml still says 4.8 while the runtime behaves as 4. Nothing warns, and the symptom surfaces somewhere unrelated — in #4925 as nightly Solcast HTTP 429s. A correctness property that depends on every call site remembering an invisible convention will drift back.

The framing that convinced me: the type is already declared authoritatively in APPS_SCHEMA, and get_arg() currently prefers an incidental literal over it. That reads as the accessor being wrong, not the callers.

There is also direct precedent — #4441 fixed this exact mechanism on the CONFIG_ITEMS route inside get_ha_config(), normalising an int default to float at the source for the same reason. This is the same bug on the apps.yaml/APPS_SCHEMA route, which get_ha_config()s normalisation cannot reach because there is no config_index entry to match. Fixing it in get_arg() keeps both routes consistent.

Two honest costs, so they are on the record rather than buried:

• it adds an APPS_SCHEMA lookup to a hot accessor (dict .get on a resolved-once global, but it is not free); and
• it makes get_arg()s return type depend on that global rather than purely on its arguments.

If you would rather keep the accessor dumb, the alternative I would want is all six call sites fixed plus a test that fails when a new int default appears against a float-declared key — the sweep in test_component_arg_specs_resolve_float_declared_keys_as_float already does roughly that for the component specs and could be widened. Without the guard I think it regresses quietly. Happy to switch it round if you prefer that shape — just say which.

(Posted by Rik; written by Claude.)

@springfall2008 following up — my reply above (2026-09-10) laid out the case for fixing this in get_arg() rather than at each caller, plus an alternative if you'd rather keep the accessor dumb (fix all six call sites + a regression test). Just flagging so it doesn't fall off your radar; happy to switch approach if you tell me which way you'd prefer.

(Written by Claude, posted by @chalfontchubby.)

@springfall2008 I've switched this to your suggestion: the get_arg() change is gone, and the callers are fixed instead.

A correction to my earlier reply: it said six call sites, but there are eight - I had missed alphaess_api_delay and axle_pence_per_kwh in components.py. All eight now use float defaults (the table in the description lists them).

To stop a ninth appearing, there is a guard test that scans the source for any get_arg() call or COMPONENT_LIST spec giving a float-declared key an int literal default, and fails naming it. Against main it names all eight. The branch is rebased onto current main as one commit, and the description is rewritten to match.